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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



£75/ 



3GPP TS 24.247 version 6.0.1 Release 6 6 ETSI TS 1 24 247 V6.0.1 (2005-01 ) 



Scope 



The present document provides the protocol details for the messaging service within the IP Multimedia CN Subsystem 
(IMS) based on the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), the Message Session 
Relay Protocol (MSRP) and the Conference Policy Control Protocol (CPCP). The document covers immediate 
messaging, session based messaging and session-based messaging conferences, as described in TS 22.340. 

Where possible the present document specifies the requirements for this protocol by reference to specifications 
produced by the IETF within the scope of SIP, SDP, MSRP and other protocols, either directly, or as modified by 
3GPP TS 24.229. 

The present document is applicable to Application Servers (ASs) , Media Resource Function Controllers (MRFCs), 
Media Resource Function Processors (MRFPs) and to User Equipment (UE) providing messaging capabilities. 

This document does not cover the signalling between a MRFC and a MRFP. 
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[II] 3GPP TS 22.340: "IP Multimedia System (IMS) messaging; Stage 1'. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions given in TS 22.340 [11] apply: 

Immediate messaging 

Session based messaging 

Session based messaging conferences 

For the purposes of the present document, the [following] terms and definitions given in draft-ietf-simple-message- 
sessions [9] apply: 

Host 

Page-mode messaging 

Session inactivity timer 

Session-mode messaging 

Session-mode messaging conferences 

Visitor 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.147 [10] apply: 

Conferencing Application Server 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AS Application Server 

CN Core Network 

DM Data manipulator 

DMS Data manipulation server 

IM IP Multimedia 

IMS IP Multimedia CN subsystem 

IP Internet Protocol 

MRFC Media Resource Function Controllers 

MRFP Media Resource Function Processors 

MSRP Message Session Relay Protocol 

SBLP Service Based Local Policy 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

UE User Equipment 

URL Uniform Resource Locator 



IVIessaging overview 



The basic services for the IP Multimedia core network Subsystem (IMS), as defined in 3GPP TS 24.229 [5], allow a 
user to initiate, modify and terminate media sessions using the Session Initiation Protocol, as defined in RFC 3261 [7]. 
Although these basic mechanisms already allow the exchange of instant messaging information using SIP, this 
functionality can be extended to provide a richer service within the IMS. 

The messaging service within the IM CN subsystem provides the means for a user to send or receive single messages 
immediately to / from another user and to create and participate in a messaging conference with one ore more other 
users. Participants to such message based communication may be internal or external to the home network. 
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When to use an immediate message and when to use a session-based messaging session will depend on the application. 

NOTE: Some participants may always use session-based messaging, while others may use immediate messaging 
or a combination of session-based messaging and immediate messaging dependant of the characteristics 
of the messaging session. The criteria are implementation and application specific. 

For immediate messaging the procedures for page-mode messaging, as defined in RFC 3428 or for session-mode 
messaging, as defined in draft-ietf-simple-message-sessions are utilized. When to use an page-mode messaging and 
when to use session-mode messaging session for the purpose of immediate messaging will depend on the application. 

For session-based messaging and session-based messaging conferences, the Message Session Relay Protocol (MSRP) is 
utilized to transport messages. 

The architecture for the 3GPP messaging is specified in 3GPP TS 23.228 [6] and 3GPP TS 23.218 [3]. 



5 Protocol using SIP for page-mode messaging 

5.1 Introduction 

5.2 Functional entities 



5.2.1 User Equipment (UE) 



For the purpose of page-mode messaging, the UE shall implement the role of a Participant as described in 
subclause 5.3.1. 

5.2.2 Application Server (AS) 

For the purpose of page-mode messaging, an Application Server may implement the role of a List Server as described 
in subclause 5.3.2. An Application Server may implement the role of a Participant as described in subclause 5.3.1 

5.3 Role 
5.3.1 Participant 

5.3.1.1 General 

For the purpose of page-mode messaging a participant will send a page-mode message using a SIP MESSAGE request 
as defined in RFC 3428 [8] to another participant. 

5.3.1 .2 Sending of an immediate message 

When sending an page-mode message to another participant, the participant shall construct and send a MESSAGE 
request in accordance with RFC 3428 [8] and subclause 5.1.2A.1 of 3GPP TS 24.229 [5]. 

5.3.1 .3 Receiving an immediate message 

Upon receipt of a MESSAGE request, the participant shall perform the procedures as described in RFC 3428 [8] and 
subclause 5.1.2A.2 of 3GPP TS 24.229 [5]. 

NOTE: A MESSAGE request can be used for applications other than immediate messaging (e.g. 

3GPP TS 23.228 [6] subclause 5.4.9), and the handling of received MESSAGE requests for such 
applications is outside the scope of this specification. 
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6 Protocol using SIP for session-mode messaging 

6.1 Introduction 

6.2 Functional entities 
6.2.1 User Equipment (UE) 

For the purpose of session-mode messaging, the UE shall implement the role of a Participant as described in 
subclause 6.3.1. 

6.3 Role 

6.3.1 Participant 

6.3.1.1 General 

The participant shall perform SIP related session procedures in accordance with 3GPP TS 24.229 [5] to set up the 
dialog used for session-based messaging. 

6.3.1 .2 Session initiation - mobile originating case 

When the originating participant wishes to engage the terminating participantin a session-mode message session, it 
shall use the call initiation procedure specified in TS 24229 [5]. The Request URI header shall include the 
URI of the terminating participant. 

6.3.1 .3 Session initiation - mobile terminating case 

When the terminating participant receives an initial INVITE request from the originating endpoint proposing a 
message session, the terminating participant shall apply the procedures as specified in 3GPP TS 
24.229 [5]. 

6.3.2 Intermediate Node 

6.3.2.1 General 

The intermediate node shall act as a Routeing B2BUA as specified in subclause 5.7 in TS 24.229 [5].. 

6.3.2.2 Generic procedures for all methods at the intermediate node 

6.3.2.2.1 Intermediate node - originating case 

The intermediate node shall follow the procedures of 3GPP TS 24.229 [5] subclause 5.7.3 when acting as an originating 
UA. 

6.3.2.2.2 Intermediate node - terminating case 

Upon receipt of an initial request the intermediate node shall follow the procedures of 3GPP TS 24.229 [5] 
subclause 5.7.1.2 in relation to the contents of the P-Charging-Function- Addresses header and the P-Charging- Vector 
header. 

When creating the first response for this initial request, the intermediate node shall: 
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1) include the P-Charging- Vector header including: 

a) the value of the icid parameter as received in the initial request; and 

b) the value of the orig-ioi parameter as received in the initial request; and 

c) the term-ioi parameter, indicating the network of the intermediate node; and 

2) include the P-Charging-Function- Addresses header as received in the initial request or, if the P-Charging- 
Function- Addresses header was not received in the initial request indicate the values applicable for the 
conference in the P-Charging-Function- Addresses header. 

When creating responses for an initial INVITE request, the intermediate node shall additionally send the 200 (OK) 
response to the initial INVITE request only after the resource reservation has been completed. 

6.3.2.3 Session Initiation 

6.3.2.3.1 Session initiation - originating case 

The intermediate node shall follow the procedures of 3GPP TS 24.229 [5] at call initiation. 
The intermediate node shall populate the INVITE as specified for a Routeing B2BUA with the following clarification: 

a) the Request URI to the URJ as in the received Request URI: 

b) the To header to the same display name and URI as in the received To header; 

c) the From header sent includes the same display name and URI as in the From header in the received INVITE; 
and 

d) the P-Asserted-Identity header and privacy includes the same information as in the received P-Asserted-Identity 
header and Privacy header; and 

If the intermediate node is not able to establish a TCP connection for the MSRP session the intermediate node shall 
send BYE towards the participant and release the associated recourses. 

6.3.2.3.2 Session initiation - terminating case 

Upon receipt of an INVITE request that includes an the terminating participant URI in the request URI, the intermediate 
node shall: 

1) verify the identity of the user as described in subclause 5.7. 1 .4 of 3GPP TS 24.229 [5] and authorize the request 
as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this subclause shall only be 
performed if the request can be authorized; and 

2) establish the session in accordance with TS 24.229 [5]. 

3) create a 200 (OK) response. 



7 Protocol using SIP for session-mode messaging 

conferences 

7.1 Introduction 

Void. 



£75/ 



3GPP TS 24.247 version 6.0.1 Release 6 1 1 ETSI TS 1 24 247 V6.0.1 (2005-01 ) 

7.2 Functional entities 

7.2.1 User Equipment (UE) 

For the purpose of session-mode messaging conferences, the UE shall implement the role of a Participant as described 
in subclause 6.3.1 and the the procedures described in subclause 5.2.1 in 3GPP TS 24.147 [10]. 

7.2.2 IVIedia Resource Function Controller (IVIRFC) 

For the purpose of session-based messaging conferences, the MRFC shall follow the procedures described in subclause 

5.2.2 in 3GPPTS 24.147 [10]. 

7.2.3 Conferencing Application Server (AS) 

For the purpose of session-based messaging conferences, the AS shall follow the procedures described in subclause 

5.2.3 in 3GPPTS 24.147 [10]. 
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Protocol using SDP for session-mode messaging 
and session-mode messaging conferences 



8.1 Introduction 

8.2 Functional entities 

8.2.1 User Equipment (UE) 

For the purpose of session-mode messaging and session-mode messaging conferences, the UE shall implement the role 
of 

an SDP offerer as described in subclause 8.3.1; and 

an SDP answerer as described in subclause 8.3.2. 

8.2.2 Media Resource Function Controller (MRFC) 

As the function split between the MRFC and the AS is out of scope of the present document, the procedures for the 
MRFC are described together with those for the AS in subclause 8.2.3. 

8.2.3 Application Server (AS) 

As the functional split between the AS and the MRFC is out of scope of the present document, the procedures are 
described for a combined AS and MRFC. The AS and MRFC may either be collocated, or interoperate using a 
proprietary protocol and a proprietary functional split. 

The AS shall implement the role of 

an intermediate node as described in subclause 8.3.3 when engaged in a session mode messaging conference; or 

a SDP offerer, as described in subclause 8.3.1, and a SDPanswerer, as described in subclause 8.3.2 when 
engaged in a session mode session between a SDP offerer and SDP answerer.NOTE: An AS, not 
performing one of the above specific functionalities, that is on the signalling path for the related SIP 
signalling, is not mandated to terminate the related MSRP. 



£75/ 



3GPP TS 24.247 version 6.0.1 Release 6 1 2 ETSI TS 1 24 247 V6.0.1 (2005-01 ) 

8.3 Role 

8.3.1 SDP offerer 

When an SDP offerer wants to create a session mode massaging session, the SDP offerer shall populate the SDP as 
specified in subclause 6.1 in TS 24.229[5]. SDP offerer shall also include: 

a) a media attribute in accordance with draft- ietf-simple-message-sessions [9]; and 

b) the supported MIME types in the accept-types or accept-wrapped-types attributes in accordance with draft-ietf- 
simple-message-sessions [9]; and 

c) the address of the SDP offerer in the path attribute, in accordance with draft-ietf-simple-message-sessions [9]. 

The SDP may also include a max-size attribute. The attribute shall be formatted in accordance with draft-ietf simple- 
message-sessions [9] 

At the receipt of the SDPanswer the SDP offerer shall set up a TCP connection (if not already available) when an IP- 
CAN bearer with sufficient QoS is available. 

8.3.2 SDP answerer 

When receiving an SDP offer the SDP answerer shall populate the SDP answer as specified in subclause 6. 1 in TS 
24.229[5]. In addition the answerer shall include: 

a) a media attribute in accordance with the received media attribute in the SDP offer; and 

b) the supported MIME types in the accept-types or accept-wrapped-types attributes in accordance with draft-ietf- 
simple-message-sessions [9]; and 

c) the MSRP URI of the SDP answerer in the path attribute in accordance with draft-ietf-simple-message- 

sessions [9]. 

The SDPmay also include a max-size attribute. The attribute shall be formatted in accordance with draft-ietf simple- 
message-sessions [9]. 

8.3.3 Intermediate node 

8.3.3.1 Intermediate node Originating case 

8.3.3.1.1 Sending of a SDP offer 

The intermediate node shall create a SDP offer, which shall include: 

a) a media attribute in accordance with the media attribute received in the received in the SDP offer.; and 

b) the supported MIME types in the accept-types or accept-wrapped-types attributes as provisioned in the 
intermediate node. The attribute shall be formatted in accordance with draft-ietf-simple-message-sessions [9]; 
and 

c) a MSRP URI of the Intermediate node in the path attribute to be used when the SDP answerer wants to send a 
MSRP message to the conference. The attribute shall be formatted in accordance with draft-ietf-simple-message- 
sessions [9]. 

The SDP may also include a max-size attribute. The attribute shall be formatted in accordance with draft-ietf simple- 
message-sessions [9]. 

At the receipt of the SDPanswer the Intermediate node shall set up a TCP connection (if not already available) when an 
IP-CAN bearer with sufficient QoS is available. 
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8.3.3.2 Intermediate node Terminating case 

8.3.3.2.1 Sending of a SDP answer 

The intermediate node shall at the receipt of a SDP offer create a SDP answer. The SDP answer shall include: 

a) a media attribute in accordance with the received media attribute in the SDP offer; and 

b) the supported MIME types in the accept-types or accept-wrapped-types attributes in accordance with draft-ietf- 
simple-message-sessions [9]; and 

c) a MSRP URI in the path attribute to be used when the SDP answerer shall send a MSRP message to the 
conference,. The attribute shall be formatted in accordance with draft-ietf-simple-message-sessions [9]. 

The SDPmay also include a max-size attribute. The attribute shall be formatted in accordance with draft-ietf-simple- 
message-sessions [9]. 

9 Protocol using MSRP for session-mode messaging 

and session-mode messaging conferences 

9.1 Introduction 

9.2 Functional entities 
9.2.1 User Equipment (UE) 

9.2.1.1 General 

The UE shall: 

implement the role of an MSRP sender as described in subclause 9.3. 1; and 
implement the role of an MSRP receiver as described in subclause 9.3.2. 



9.2.2 Application Server (AS) 

As the functional split between the AS and the MRFP is out of scope of the present document, the procedures are 
described for a combined messaging conferencing AS and MRFP. The AS and MRFP may either be collocated, or 
interoperate using a proprietary protocol and a proprietary functional split. 

For the purpose of an AS acting either as: 

an endpoint for session-mode messaging; 

an intermediate node for session-mode messaging; or 

a conferencing AS for session-mode messaging conferences, 
the AS shall implement the role of: 

an intermediate node as described in subclause 9.3.3 when engaged in a session mode messaging conference; or 

a MSRP sender , as described in subclause 9.3.1, and a MSRP receiver, as described in subclause 9.3.2 when 
engaged in a session mode session between a MSRP senderer and MSRP receiver. 
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NOTE: An AS, not performing one of the above specific functionalities, that is on the signalling path for the 
related SIP signalling, is not mandated to terminate the related MSRP. 

9.2.3 Media Resource Function Processor (MRFP) 

As the function split between the MRFP and the conferencing AS is out of scope of the present document, the 
procedures for the MRFP are described together with those for the AS in subclause 9.2.2. 

9.3 Role 

9.3.1 MSRP sender 

9.3.1.1 MSRP sender sends a message 

When a MSRP sender wishes to send a message, the MSRP sender shall ensure that the message length is not longer 
than the max-size attribute, as received in a SDP offer or a SDP answer. Depending on the message length the message 
may be included in one SEND request or chunked into a number of SEND requests. The MSRP sender shall follow the 
procedures and rules as specified in draft-ietf-simple-message-sessions [9], when the MSRP sender fragments a 
message into a number SEND requests. 

The MSRP sender shall create a SEND request in accordance with draft- ietf-simple-message-sessions [9], where the 
value of To-Path is the MSRP URI shall be set to value of path attribute received in a SDP offer or a SDP answer.. 

9.3.2 MSRP receiver 

When a MSRP receiver receives a SEND request, the MSRP receiver shall parse the SEND request. The MSRP 
receiver shall either send a response including: 

a) a 200 (OK) status-code , as specified in draft-ietf-simple-message-sessions [9], for the concerned SEND message 
if the parsing was successful; or 

b) an appropriate status-code, as specified in draft-ietf-simple-message-sessions [9], for the concerned SEND 
message if the parsing was unsuccessful. 

The MSRP receiver shall send a REPORT request if this is explicit or implicit requested in the SEND request(s) 
belonging to the message. It shall either be: 

a) a successful REPORT request including status-code 200 (OK) if a complete message is received and the Report- 
Success header in the SEND request was set to 'yes'; or 

b) an unsuccessful REPORT request including status-code other than 200 (OK) as defined in draft-ietf-simple- 
message-sessions [9] if the MSRP receiver can conclude that a complete message is not received and the 
Report-Failure header is set to 'yes' or not included. The criteria to conclude that a complete message is not 
received are specified in draft-ietf-simple-message-sessions [9]. 

9.3.3 Intermediate node 

9.3.3.1 Intermediate node terminating case 

When an intermediate node receives a SEND request, the intermediate node shall: 
1) parse the SEND request and either send a response including: 

a) a 200 (OK) status-code, as specified in draft-ietf-simple-message-sessions [9], for the concerned SEND 
message, if the parsing was successful; or 

b) an appropriate status-code, as specified in draft-ietf-simple-message-sessions [9], for the concerned SEND 
message if the parsing was unsuccessful.; and 
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2) determine that a complete message has been received. The following actions in this subclause shall only be 
performed if a complete message is received. 

The MSRP receiver shall send a REPORT request if this is explicit or implicit requested in the SEND request(s) 
associated to the same message. It shall either be: 

a) a successful REPORT request including status-code 200 (OK) if the intermediate node concludes that all 
available users on the distribution list has received the complete message or a concerned user has received the 
complete message and the Report-Success header in the SEND request was set to 'yes'; or 

b) an unsuccessful REPORT request including status-code other than 200 (OK) as defined in draft-ietf-simple- 
message-sessions [9] if the intermediate node conclude that a complete message has not been received or that a 
complete message has not been able to be delivered to all available users on the distribution list or to a particular 
member of the distribution list. 

9.3.3.2 Intermediate node originating case 

When an intermediate node wishes to send a message, the intermediate shall ensure that the message length is not 
longer than the max-size attribute, as received in a SDP offer or a SDP answer. Depending on the message length the 
message may be included in one SEND request or chunked into a number of SEND requests. The intermediate shall 
follow the procedures and rules as specified in draft-ietf-simple-message-sessions [9], when the intermediate node 
fragments a message into a number SEND requests. 

The intermediate shall create a SEND request in accordance with draft-ietf-simple-message-sessions [9] with the 
following clarifications: 

1) set the Report-Success header as received in the SEND request; 

2) set the Report-Failure header as received in the SEND request; and 

3) depending on the received MSRP URI 

a) either send the SEND request to all available user of the conference; or 

b) send the SEND request to one MSRP receiver. 



1 Protocol for data manipulation at the Ut reference 
point 

10.1 Introduction 

10.2 Functional entities 



1 0.2.1 User Equipment (UE) 



For the purpose of SIP based conferences, the UE may implement the role of a XCAP client as described in 
subclause 10.3.1. 

The UE shall implement HTTP digest AKA (see RFC 3310 [X]) and it shall initiate a bootstrapping procedure with the 
bootstrapping server function located in the home network, as described in 3GPP TS 24.109 [YY]. 

The UE shall acquire the subscriber's certificate from PKI portal by using a bootstrapping procedure, as described in 
3GPPTS 24.109 [YY]. 

The UE shall implement Transport Layer Security (TLS) (see RFC 2246 [Y]). The UE shall be able to authenticate the 
authentication proxy based on the received certificate during TLS handshaking phase. 
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1 0.2.2 Media Resource Function Controller (MRFC) 

As the function split between the MRFC and the AS is out of scope of the present document, the procedures for the 
MRFC are described together with those for the AS in subclause 10.2.3. 



1 0.2.3 Application Server (AS) 

The AS shall implement the role of a XCAP server as described in subclause 10.3.2. As the function split between the 
AS and the MRFC is out of scope of the present document, only the procedures are described for a combined AS and 
MRFC. The AS and MRFC may either be collocated, or interoperate using a proprietary protocol and a proprietary 
functional split. 

For the purpose of SIP-based conferences, the AS/MRFC shall act as a XCAP Server, as described in subclause 10.3.2. 

The AS/MRFC may implement the role of a privileged user as described in subclause 7.3.1. 

If there is no authentication proxy in the network, then the AS/MRFC shall: 

implement the role of a network application function, as described in 3GPP TS 24.109 [YY]; 

support HTTP digest authentication and certificate authentication; and 

- implement TLS (see RFC 2246 [Y]). 

Editor's Note: It needs to be clarified what physical entities can contain the Authentication Proxy and its relationship 
with the IMS architecture. Documentation for the case of a separate authentication proxy may need to be 
provided. 

10.3 Role 

10.3.1 XCAP client 

A XCAP client shall support the manipulation of some or all of the conferencing policy data elements that are defined 
in draft-ietf-xcon-cpcp-xcap [Z]..The XCAP client shall comply with the requirement as specified for a privileged user 
role in subclause 5.3.1 in TS 24.147 [10]. 

10.3.2 XCAP Server 

The XCAP server shall comply with the requirement as specified for a conference policy server role in subclause 5.3.1 
in TS 24. 147 [10]. 
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Annex A (informative): 

Example signalling flows of messaging service operation 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for conferencing within the IP Multimedia CN Subsystem (IMS) based 
on the Session Initiation Protocol (SIP), SIP Events, the Session Description Protocol (SDP) and other protocols. 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.228 [6]. 

A.2 Introduction 

A.2.1 General 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [4] subclause 4. 1 applies with the additions specified 
below. 

In order to differentiate between messages for SIP and MSRP, the following notation is used: 

INVITE 



► SIP message 

_ ^^_ ^^^ Reliable transport protocol messages 

"^^ (in bold style) 

SEND 



MRSP message (in bold style) 



Figure A.2.2-1 : Signalling flow notation 

A.3 Signalling flows demonstrating immediate messaging 

The signalling flow for immediate messaging is shown in subclause 10.6 of 3GPP TS 24.228 [4]. 

A.4 Signalling flows demonstrating session-based messaging 
A.4.1 Introduction 

This subclause provides signalling flows for session-based messaging, established both with and without preconditions. 
How the signalling flow for session-based messaging looks like depends on the following: 

a) at what point in time the IP-CAN for the media component (MSRP) is set up; or 

b) whether preconditions and reliable provisional responses are used or not. 
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A.4.2 Establishing a session for session-based messaging 
without preconditions 

Figure A.4.2- 1 shows the establishment of an MSRP session between two users without the usage of preconditions and 
reUable provisional responses as well as the first message being sent over the established connection. 

It is assumed that both the originating UE and terminating UE are using an IP-CAN with a separate bearer for SIP 
signalling which means that each UE needs to reserve a new IP -CAN bearer for the message session media component 
prior to sending the first MSRP message. 
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UE#1 Home Network 



UE#2 Home Network 



UE#2 Visited Network 



UE#1 



I 



P-CSCF#1 



1 . Reserve IP- 
CAN bearer for 
media 



-2. INVITE ► 



-3. lOOTrying- 



-26. 200 OK— 
—27. ACK > 



S-CSCF#1 



4. INVITE- 
'S. 100 Trying - 



l-CSCF#2 



6. Evaluation of Initial 
Filter Criteria 



-25. 200 OK- 



-28. ACK ► 



-7. INVITE ► 



100 Trying - 



S-CSCF#2 



9. HSS query 



— 10. INVITE — 
-11. lOOTrying- 



P-CSCF#2 



12. Evaluation of 
Initial Filter Criteria 



i18. TCP setup 

I 
^19. VISITh 

I 
—20. 200 OK- 



< 24. 200 OK- 



-23. 200 OK- 



-29. ACK- 



-32. SEND- 

I 
■ 33.200OK1 



— 13. INVITE — 
-14. 100 Trying — 



-22. 200 OK- 



-30. ACK ► 



UE#2 



-15. INVITE- 



-16. 100. Trying- 



17. Reserve IP-CAN 
bearer for media 



-21.200OK- 



-31. ACK ► 

► 



Figure A.4.2-1 : Establishment of MSRP session 
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The details of the signalling flows are as follows: 

1 . Reserve IP-CAN bearer for media 

The originating UE wants to initiate a session-based message session with the terminating UE. The 
originating UE reserves an IP-CAN bearer for the message session media component. 

2. INVITE request (UE#1 to P-CSCF#1) - see example in table A.4.2-2 

The originating UE creates a local MSRP URL, which can be used for the communication between the two 
user agents. It builds a SDP Offer containing the generated MSRP URL and assigns a local port number for 
the MSRP communication. 

Table A.4.2-2: INVITE request (UE#1 to P-CSCF#1) 



INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip:orig@scscfl. homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip:userl_publicl@homel . net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To : <sip : user2_publicl@home2 . net> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi-c=98765432; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip: [5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

C=IN IP6 my . ms rp . dummy . URL 

t = 

m=message 9999 msrp * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [5555: : aaa: bbb: ccc : ddd] :3402/slll271 



3. 100 (Trying) response (P-CSCF#1 to UE#1) - see example in table A.4.2-3 

The P-CSCF responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.2-3: 100 (Trying) response (P-CSCF#1 to UE#1) 



SIP/2.0 100 Trying 








Via: SIP/2. 0/UDP [5555: 


: aaa : bbb : ccc : ddd] 


1357, 


comp=sigcomp; branch=z9hG4bKnashds7 


From: 








To: 








Call-ID: 








CSeq: 








Content-Length: 









4. INVITE request (P-CSCF#1 to S-CSCF#1) - see example in table A.4.2-4 

The INVITE request is forwarded to the S-CSCF. 



£75/ 



3GPP TS 24.247 version 6.0.1 Release 6 21 ETSI TS 124 247 V6.0.1 (2005-01) 

Table A.4.2-4: INVITE request (P-CSCF#1 to S-CSCF#1) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : <sip:orig@scscfl. homel .net; lr> 
Record-Route : <sip:pcscfl. visitedl. net;lr> 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net> 
P-Access-Network-Inf o : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 



5. 100 (Trying) response (S-CSCF#1 to P-CSCF#1) - see example in table A.4,2-5 

The S-CSCF responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.2-5: 100 (Trying) response (S-CSCF#1 to P-CSCF#1) 



SIP/2.0 100 Trying 


Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 


[5555 : : aaa: bbb: ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 


From: 


To: 


Call-ID: 


CSeq: 


Content-Length: 



6. Evaluation of initial filter criteria 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. 

7. INVITE request (S-CSCF#1 to I-CSCF#2) - see example in table A.41-7 

S-CSCF#1 forwards the INVITE request to the I-CSCF#2. 
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Table A.4.2-7: INVITE request (S-CSCF#1 to l-CSCF#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Record-Route : <sip:scscfl. homel .net;lr>, <s ip:pcscfl. visitedl. net; lr> 
P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net>, <tel : +l-212-555-llll> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



100 (Trying) response (I-CSCF#2 to S-CSCF#1) - see example in table A.4.2-8 

I-CSCF#2 sends a 100 (Trying) response provisional response to S-CSCF#1. 

Table A.4.2-8: 100 (Trying) response (l-CSCF#2 to S-CSCF#1) 



SIP/2.0 100 Trying 
















Via: SIP/2. 0/UDP scsc 


f 1 .homel 


net;branch=z9hG4bK332b23.1, SIP/2. 


0/UDP 


pcscfl. visitedl 


ne 


t; branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb:ccc 


:ddd] 


1357; comp=sigcomp; b 


ranch= 


z9hG4bKnashc 


s7 


From: 
















To: 
















Call-ID: 
















CSeq: 
















Content-Length: 

















9. Cx: User Location Query procedure 

The 1-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

10. INVITE request (I-CSCF#2 to S-CSCF#2) - see example in table A.4.2-10 

I-CSCF#2 forwards the INVITE request to the S-CSCF#2 that will handle the session termination. 
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Table A.4.2-10: INVITE request (l-CSCF#2 to S-CSCF#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s .home2 .net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscf 1 .homel . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip: scscf 2 .home2 . net; lr> 

Record-Route : 

P -As sorted- Identity : 

P-Charging-Vector : 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Allow: 

Content-Type : 

Content-Length : 



11. 100 (Trying) response (S-CSCF#2 to I-CSCF#2) - see example in table A.4.2-11 

S-CSCF#2 responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.2-11 : 100 (Trying) response (S-CSCF#2 to l-CSCF#2) 



SIP/2.0 100 Trying 














Via: SIP/2. 0/UDP icscf2_s. 


home2 


. net; branch=z 


9hG4bK871 


yl2.1. 


SIP/2. 


0/UDP 


scscf 1 


homel . net; branch 


=z9hG4bK332b23.1, 


SIP/2. 0/UDP 






pcscf 1 


visitedl. net ;branch=z 


9hG4bK240f34. 


1, SIP/2. 


0/UDP 






[5555: 


aaa : bbb : ccc : ddd] 


:1357 


; comp=sigcomp; branch=z 


9hG4bK 


nashds7 




From: 
















To: 
















Call-ID: 
















CSeq: 
















Content-Length: 















12. Evaluation of initial filter criterias 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias. 

13. INVITE request (S-CSCF#2 to P-CSCF#2) - see example in table A.4.2-13 

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. S-CSCF#2 remembers 
(from the registration procedure) the UE Contact address and the next hop CSCF for this UE. 
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Table A.4.2-13: INVITE request (S-CSCF#2 to P-CSCF#2) 



INVITE sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 66 

Route : <sip:pcscf2.visited2.net;lr> 

Record-Route : <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel .net; lr>, 
<sip:pcscfl .visitedl . net; lr> 

P -Asserted- Identity: 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Allow: 

P-Called-Party-ID: <sip: user2_publicl@home2 . net> 

Content-Type : 

Content-Length: (...) 



14. 100 (Trying) response (P-CSCF#2 to S-CSCF#2) - see example in table A.4.2-14 

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request. 

Table A.4.2-14: 100 (Trying) response (P-CSCF#2 to S-CSCF#2) 



SIP/2.0 100 Trying 












Via: SIP/2. 0/UDP scsc 


f2 .home2 . net ; branch=z9hG4bK7 64z 


87.1, SIP/2. 


0/UDP 


icscf2 


s . home2 . net 


;branch=z9hG4bK871yl2.1 


, SIP/2. 


0/UDP 




scscfl 


homel . net ; b 


ranch= 


=z9hG4bK332b23.1, 


SIP/2. 0/UDP 




pcscf 1 


visitedl . ne 


t;branch=z9hG4bK240f34. 


1, SIP/2 


.0/UDP 




[5555: 


aaa: bbb: ccc 


:ddd] 


1357; comp=sigcomp 


; branch= 


z9hG4bKnashc 


s7 


From: 














To: 














Call-ID: 














CSeq: 














Content-Length: 













15. INVITE request (P-CSCF#2 to UE#2) - see example in table A.4.2-15 

P-CSCF#2 forwards the INVITE request to the terminating UE. 
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Table A.4.2-15: INVITE request (P-CSCF#2 to UE#2) 



INVITE sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .visited2 . net : 5088; comp=sigcomp;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards : 65 
Record-Route : <sip:pcscf2 .visited2 . net ; 5088; Ir; comp=sigcomp>, <sip: scscf2 . home 2 . net ; lr>, 

<sip: scscfl . homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 
P -Asserted- Identity : 
Privacy : 
From; 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

P-Called-Party-ID : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



16. 100 (Trying) response (UE#2 to P-CSCF#2) - see example in table A.4.2-16 

The terminating UE sends a 100 (Trying) response provisional response to P-CSCF#2. 

Table A.4.2-16: 100 (Trying) response (UE#2 to P-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 2 .visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .homel . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



17. Reserve IP-CAN bearer for media 

The terminating UE accepts the message session. The terminating UE reserves an IP-CAN bearer for the 
message session media component. 

18. TCP setup 

The terminating UE establishes a TCP connection using the IP -CAN bearers established in step 1 and step 17 
to the host address and the port as specified in the MSRP URL received in the SDP Offer from the 
originating UE. 

19. MSRP VISIT request (UE#1 to UE#2) - see example in table A.4.2-19 

The terminating UE sends an MSRP VISIT request using the established TCP connection. 
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Table A.4.2-19: MSRP VISIT request (UE to UE) 



MSRP VISIT 

Boundary: dkei38sd 

To-path:msrp: // [5555: : aaa:bbb: ccc : ddd] :3402/slll271 

From-path:msrp: // [5555: : eee : f f f : aaa : bbb] :3333/s234167 

TR-ID: 2810 

Message-ID: 2810 

dkei38sd$ 



Boundary: Boundary string used to terminate message 

To-path: The sender" s remote path 

From-path: The sender" s local URL 

TR-ID: A unique transaction ID for this MSRP transaction. 

Message-ID: A unique message ID for MSRP message. 

Closing: Same boundary string as well as Continuation-Flag 

20. MSRP 200 (OK) response (UE#2 to UE#1) - see example in table A.4.2-20 

The originating UE that acts as an MSRP host returns an MSRP 200 (OK) response to the MSRP VISIT 
request using the established TCP connection. 

Table A.4.2-20: 200 (OK) response (UE#2 to UE#1) 



MSRP 200 OK 

Boundary: wej28su 

To-path :msrp: // [5555: : aaa: bbb: ccc : ddd] :3402/slll271 

From-path :msrp:// [5555: : eee : f f f : aaa:bbb] :3333/s234167 

TR-ID: 2810 

we j2 8su$ 



TR-ID: The transaction ID for this MSRP transaction, as received in the related MSRP request. 

21. 200 (OK) response (UE#2 to P-CSCF#2) - see example in table A.4.2-21 

After the receipt of the the MSRP 200 (OK) response to the MSRP VISIT request, the terminating UE sends 
a 200 (OK) response for the INVITE request containing SDP that indicates that the terminating UE has 
successfully visited to the originating UE. 
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Table A.4.2-21 : 200 (OK) response (UE#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 .vis it edl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route ; <sip;pcscf2 .visited2 . net ; 5088; Ir; comp=sigcomp>>, <sip; scscf2 . home 2 .net; lr>, 

<sip; scscfl . homel .net;lr>, <sip;pcscfl.visitedl.net;lr> 
Privacy; none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From; <sip : userl_publicl@homel . net>; tag=171828 
To: <sip:user2_publicl@home2 . net>; tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 INVITE 

Contact: <sip: [5555: :eee:fff: aaa: bbb] : 8 805; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 my. MSRP. dummy. URL 

t = 

m=message 9999 msrp * 

a=accept-types : text/plain text/html message/cpim 

a=path:msrp:// [5555: : eee : f f f : aaa:bbb] :3333/s234167 



22. 200 (OK) response (P-CSCF#2 to S-CSCF#2) - see example in table A.4.2-22 

P-CSCF#2 forwards the 200 (OK) response to S-CSCF#2. 

Table A.4.2-22: 200 (OK) response (P-CSCF#2 to S-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 
pcscf 1 .vis it edl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : 

P-Asserted-Identity : John Smith" <sip : user2_publicl@home2 . net> 

Privacy : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 

P-Access-Network-Inf o : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Allow: 

Content-Type : 

Content-Length : 



23. 200 (OK) response (S-CSCF#2 to I-CSCF#2) - see example in table A.4.2-23 

S-CSCF#2 forwards the 200 (OK) response to I-CSCF#2. 
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Table A.4.2-23: 200 (OK) response (S-CSCF#2 to l-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route : 

P-Asserted-Identity : "John Smith" <sip:user2_publicl@home2 . net>, <tel : +l-212-555-2222> 
Privacy ; 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net; 

term-ioi=home2 . net 
P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22]; 

ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 



24. 200 (OK) response (I-CSCF#2 to S-CSCF#1) - see example in table A.4.2-24 

I-CSCF#2 forwards the 200 (OK) response to S-CSCF#1. 

Table A.4.2-24: 200 (OK) response (l-CSCF#2 to S-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : 

P-Asserted- Identity: 

Privacy: none 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Allow: 

Content-Type : 

Content-Length : 



25. 200 (OK) response (S-CSCF#1 to P-CSCF#1) - see example in table A.4.2-25 

S-CSCF#1 forwards the 200 (OK) response to P-CSCF#1. 
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Table A.4.2-25: 200 (OK) response (S-CSCF#1 to P-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route : 
P -Asserted- Identity: 
Privacy : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



26. 200 (OK) response (P-CSCF#1 to UE#1) - see example in table A.4.2-26 

P-CSCF#1 forwards the 200 (OK) response to the originating UE. 

Table A.4.2-26: 200 (OK) response (P-CSCF#1 to UE#1) 



SIP/2.0 200 OK 

Via: SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : <sip:pcscf2.visited2.net;lr>, <sip:scscf2. home 2 .net; lr>, 

<sip: scscfl . homel . net; lr>, <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp> 
P -Asserted- Identity : 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



27. ACK request (UE#1 to P-CSCF#1) - see example in table A.4.2-27 

The UE responds to the 200 (OK) response with an ACK request sent to the P-CSCF#1. 
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Table A.4.2-27: ACK request (UE#1 to P-CSCF#1) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa:bbb: ccc: ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip: scscfl . homel .net; lr>, 

<sip: scscf2 . home 2 .net;lr>, <sip:pcscf2.visited2.net;lr> 
From: <sip : userl_publicl@homel .net>;tag=171828 
To : <sip : user2_publicl@home2 .net>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 ACK 
Content-Length: 



28. ACK request (P-CSCF#1 to S-CSCF#1) - see example in table A.4.2-28 

The P-CSCF#1 forwards the ACK request to S-CSCF#1. 

Table A.4.2-28: ACK request (P-CSCF#1 to S-CSCF#1) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 


Via: SIP/2. 0/UDP pcscfl . visitedl . net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 


[5555 : : aaa:bbb: ccc : ddd] : 1357; comp=sigcomp;branch=z9hG4bKnashds7 


Max-Forwards: 69 


P-Access-Network-Inf o : 


Route: <sip: scscfl .homel . net; lr>, <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 


From: 


To: 


Call-ID: 


Cseq: 


Content-Length : 



29. ACK request (S-CSCF#1 to S-CSCF#2) - see example in table A.4.2-29 

The S-CSCF#1 forwards the ACK request to the the S-CSCF#2. 

Table A.4.2-29: ACK request (S-CSCF#1 to S-CSCF#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: <sip: scscf2 .home2 . net; lr>^ <sip:pcscf2 . visited2 . net; lr> 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 



30. ACK request (S-CSCF#2 to P-CSCF#2) - see example in table A.4.2-30 

S-CSCF#1 forwards the ACK request to P-CSCF#2. 
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Table A.4.2-30: ACK request (S-CSCF#2 to P-CSCF#2) 



ACK sip: [5555: :eee 


f f f : aaa 


bbb] 


:8805 


comp 


=sigcomp 


SIP/2.0 




Via: SIP/2. 0/UDP scscf2 .home2 .net;branch= 


z9hG4bK764z87.1, SIP/2. 


0/UDP 


scscf 1 .homel . net; branch= 


z9hG4bK332b23. 


1, SIP/2 


0/UDP 




pcscfl .visitedl 


net ; branch=z 


9hG4bK240f34.1, SIP/2. 0/UDP 




[5555: :aaa:bbb:ccc:ddd] : 


1357 


; comp= 


=sigc 


omp; branch=z9hG4bKnashc 


s7 


Max-Forwards : 67 
















Route: <sip:pcscf2 


visitedz 


. net 


;lr> 










From: 
















To: 
















Call-ID: 
















Cseq: 
















Content-Length : 

















31. ACK request (P-CSCF#2 to UE#2) - see example in table A.4.2.31 

P-CSCF#2 forwards the ACK request to the terminating UE. 

Table A.4.2-31 : ACK request (P-CSCF#2 to UE#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

pcscfl .visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 66 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



32. MSRP SEND request (UE#1 to UE#2) - see example in table A.4.2-32 

The originating UE sends the first message over the MSRP session with an MSRP SEND request using the 
established TCP connection. 

Table A.4.2-32: MSRP SEND request (UE#1 to UE#2) 



MSRP SEND 

Boundary: d93kswow 

To-path:msrp:// [5555: : eee : f f f : aaa : bbb] :3333/s234167 

From-path:msrp: // [5555: : aaa : bbb : ccc : ddd] :3402/slll271 

TR-ID: 8 822 

Message-ID: 8822 

Content-Type: "text/plain" 

those are my principles. If you don't lilce them I have others - Groucho Marx. 
d93]<swow$ 



Boundary: Boundary string used to terminate message 

To-path: The sender" s remote path 

From-path: The sender" s local URL 

TR-ID: A unique transaction ID for this MSRP transaction. 

Message-ID: A unique message ID for MSRP message. 

Content-Type: The format of the body of the request. 

Closing: Same boundary string as well as Continuation-Flag 
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33. MSRP 200 (OK) response (UE#2 to UE#1) - see example in table A.4.2-33 

The terminating UE acknowledges the reception of the MSRP SEND request with an MSRP 200 (OK) response 
using the established TCP connection. 

Table A.4.2-33: MSRP 200 (OK) response (UE#2 to UE#1) 



MSRP 200 OK 

Boundary: 839s9ed 

To-path:msrp: // [5555: : eee : f f f : aaa : bbb] :3333/s234167 

From-path:msrp: // [5555: : aaa : bbb : ccc : ddd] :3402/slll271 

TR-ID: 8822 

839s9ed$ 



TR-ID: The transaction ID for this MSRP transaction, as received in the related MSRP request. 

A.4.3 Establishing a session for session-based messaging with 
Intermediate Nodes 

Figure A.4.3- 1 shows the establishment of a MSRP session between two users with intermediate nodes being added to 
the signalling path as well as the first message being sent over the established connection. 

It is assumed that both the originating UE and terminating UE are using an IP -CAN with a separate bearer for SIP 
signalling which means that each UE needs to reserve a new IP -CAN bearer for the message session media component. 
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Figure A.4.3-1 : Establishment of MSRP session with Intermediate Nodes 

Editor"s Note: It is FFS if the labelling of the intermediate nodes should be AS or AS/MRFC/MRFP. 
The details of the signalling flows are as follows: 

1 . Reserve IP-CAN bearer for media 

The originating UE#1 wants to initiate a session-based message session with the terminating UE#2. UE#1 
reserves an IP-CAN bearer for the message session media component. 

2. INVITE request (UE#1 to P-CSCF#1) - see example in table A.4.3-2 

UE#1 creates a local MSRP URL, which can be used for the communication between the two user agents. It 
builds a SDP Offer containing the generated MSRP URL and assigns a local port number for the MSRP 
communication. 
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Table A.4.3-2: INVITE request (UE#1 to P-CSCF#1) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa:bbb: ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip:orig@scscfl. homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip:userl_publicl@homel . net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To : <sip:user2_publicl@home2 .net> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi=87654321; portl=7531 

Contact: <sip: [5555: :aaa: bbb : ccc : ddd] : 1357; comp=sigcomp> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 my . ms rp . dummy . URL 

t = 

m=message 9999 msrp * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp:// [5555: : aaa: bbb: ccc: ddd] :3402/slll271 



3. 100 (Trying) response (P-CSCF#1 to UE#1) - see example in table A.4.3-3 

The P-CSCF responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.3-3: 100 (Trying) response (P-CSCF#1 to UE#1) 



SIP/2.0 100 Trying 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



4. INVITE request (P-CSCF#1 to S-CSCF#1) - see example in table A.4.3-4 

The INVITE request is forwarded to the S-CSCF. 
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Table A.4.3-4: INVITE request (P-CSCF#1 to S-CSCF#1) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : <sip:orig@scscfl. homel .net; lr> 
Record-Route : <sip:pcscfl. visitedl. net;lr> 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net> 
P-Access-Network-Inf o : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 



5. 100 (Trying) response (S-CSCF#1 to P-CSCF#1) - see example in table A.4.3-5 

The S-CSCF responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.3-5: 100 (Trying) response (S-CSCF#1 to P-CSCF#1) 



SIP/2.0 100 Trying 


Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 


[5555 : : aaa: bbb: ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 


From: 


To: 


Call-ID: 


CSeq: 


Content-Length: 



6. Evaluation of initial filter criterias 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. For 
sip:userl_publicl@homel.net S-CSCF#2 has origination initial filter criteria with service points of interest 
of Method = INVITE request and SDP m= 'message' and 'msrp' protocol that informs the S-CSCF to route 
the INVITE request to the AS sip:asl. homel. net. 

7. INVITE request (S-CSCF#1 to AS#1) - see example in table A.4.3-7 

S-CSCF#1 forwards the INVITE request to the AS#1. 
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Table A.4.3-7: INVITE request (S-CSCF#1 to AS#1) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK344a65 . 1, SIP/2. 0/UDP 

pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route : <sip : asl . homel .net;lr>, <sip:cb03a0s0 9a2sdfglkj4 90333@scscfl. homel .net; lr> 
Record-Route : <sip:orig@scscfl. homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 
P-Asserted-Identity : "John Doe" <sip : userl_publicl@homel . net>, <tel : +l-212-555-llll> 
P-Access-Network-Inf o : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 
P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22]; 

ecf=[5555: : If f : 2ee : 3dd: 4ee] ; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



100 (Trying) response (AS#1 to S-CSCF#1) - see example in table A.4.3-8 

AS#1 sends a 100 (Trying) response provisional response to S-CSCF#1. 

Table A.4.3-8: 100 (Trying) response (AS#1 to S-CSCF#1) 



SIP/2.0 100 Trying 
















Via: SIP/2. 0/UDP scsc 


f 1 . homel 


net;branch=z9hG4bK344a 


65.1, SIP/2. 


0/UDP 


pcscfl .visitedl 


ne 


t ; branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb:ccc 


:ddd] 


1357 ; comp=sigcomp; b 


ranch= 


z9hG4bKnashc 


s7 


From: 
















To: 
















Call-ID: 
















CSeq: 
















Content-Length: 

















9. TCP setup 

AS#1 establishes a TCP connection using the IP -CAN bearers established in step 1 to the host address and 
port as specified in the MSRP URL received in the SDP Offer from the originating UE#1. 

10. INVITE request (AS#1 to S-CSCF#1) - see example in table A.4.3-10 

AS#1 sends a new INVITE request to the S-CSCF#1 with the session attribute containing a unique URL for 
the AS#1 to receive media on. 
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Table A.4.3-10: INVITE request (AS#1 to S-CSCF#1) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP asl .homel . net;branch=z9hG4bK240f 34 . 1 

Max-Forwards: 70 

Route: <sip: cb03a0s0 9a2sdfglk j4 90333@scscf 1 .homel . net; lr> 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net>, <tel : +l-212-555-llll> 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323551024 " 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=234567 

To : <sip:user2_publicl@home2 .net> 

Call- ID: s0 9a233cbsdfglkj4 90303a0 

Cseq: 278 INVITE 

Contact: <sip: [7777: : eee : ddd: ccc : aaa] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933620 2987933620 IN IP6 7777 :: eee : ddd: ccc : aaa 

s=- 

c=IN IP6 asl .homel .net .URL 

t = 

m=message 9999 msrp * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [7777: : eee : ddd: ccc : aaa] :3927/s222371 



1 1. 100 (Trying) response (S-CSCF#1 to AS#1) - see example in table A.4.3-11 

S-CSCF#1 sends a 100 (Trying) response provisional response to AS#1. 

Table A.4.3-11 : 100 (Trying) response (S-CSCF#1 to AS#1) 



SIP/2 


.0 


100 


Trying 














Via: 


SIP/2. 


0/UDP asl 


homel 


net 


bran 


ch= 


= z9hG4bK240f34 


1 


From: 




















To: 




















Call- 


ID 


















CSeq: 




















Conte 


nt- 


-Len 


gth: 















12. INVITE request (S-CSCF#1 to I-CSCF#2) - see example in table A.4.3-12 

S-CSCF#1 forwards the INVITE request to the 1-CSCF#2. As the S-CSCF#1 does not know whether the I- 
CSCF at home2.net is a loose router or not, it does not introduce a Route header. 
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Table A.4.3-12: INVITE request (S-CSCF#1 to l-CSCF#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

asl.homel.net;branch=z9hG4bK24 0f34. 1 
Max-Forwards: 69 

Record-Route : <sip:scscfl. homel .net; lr> 
P-As sorted- Identity: 

P-Charging-Vector : icid-value = "AyretyU0dm+6O2IrT5tAFrbHLso = 323551024 " ; orig-ioi=homel .net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 

3 = 
C= 

t = 

m= 
a= 
a= 



13. 100 (Trying) response (I-CSCF#2 to S-CSCF#1) - see example in table A.4.3-13 

I-CSCF#2 sends a 100 (Trying) response provisional response to S-CSCF#1. 

Table A.4.3-13: 100 (Trying) response (l-CSCF#1 to S-CSCF#1) 



SIP/2.0 100 Trying 




Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 


SIP/2. 0/UDP 


asl. homel. net;branch=z9hG4bK240f34.1 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





14. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

15. INVITE request (I-CSCF#2 to S-CSCF#2) - see example in table A.4.3-15 

I-CSCF#2 forwards the INVITE request to the S-CSCF#2 that will handle the session termination. 
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Table A.4.3-15: INVITE request (l-CSCF#2 to S-CSCF#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s .home2 .net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net ; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

asl.homel.net;branch=z9hG4bK240f34. 1 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr> 
Record-Route : 
P-As sorted- Identity: 
P-Charging-Vector : 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



NOTE: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalling 
path once the session is established. 

16. 100 (Trying) response (S-CSCF#2 to I-CSCF#2) - see example in table A.4.3-16 

S-CSCF#2 responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.3-16: 100 (Trying) response (S-CSCF#2 to l-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2 . 0/UDP 

asl.homel.net;branch=z9hG4bK240f34. 1 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



17. Evaluation of initial filter criterias 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias. For 
sip: user2 publicl@home2.net S-CSCF#2 has termination initial filter criteria with service points of interest 
of Method = INVITE request and SDP m = 'message' and 'msrp' protocol that informs the S-CSCF to route 
the INVITE request to the AS sip:as2.home2.net. 

18. INVITE request (S-CSCF#2 to AS#2) - see example in table A.4.3-18 

S-CSCF#2 forwards the INVITE request to AS#2 
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Table A.4.3-18: INVITE request (S-CSCF#2 to AS#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

asl.homel.net;branch=z9hG4bK24 0f34. 1 
Max-Forwards : 67 

Route : <sip : as2 . home 2 . net; lr>, <sip : s0 9a233cbsclfglkj4 90303a0@scscf2 . home 2 .net; lr> 
Record-Route : <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel .net; lr> 
P -As sorted- Identity : 
P-Charging-Vector : 
P-Charging-Funct ion-Addresses: ccf=[6666: :b99:c88:d7 7:e66]; ccf=[6666: :a55:b44:c33:d22] 

ecf=[6666::lff:2ee:3dd:4ee]; ecf=[6666:: 6aa:7bb: 8cc: 9dd] 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 



19. 100 (Trying) response (AS#2 to S-CSCF#2) - see example in table A.4.3-19 

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request. 

Table A.4.3-19: 100 (Trying) response (AS#2 to S-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 .home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscf 1 .homel . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
asl.homel.net;branch=z9hG4bK24 0f34. 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



20. TCP setup 

AS#2 establishes a TCP connection to the host address and port as specified in the MSRP URL received in 
the SDP Offer from the AS#1. 

21. INVITE request (AS#2 to S-CSCF#2) - see example in table A.4.3-21 

AS#2 sends a new INVITE request to the S-CSCF#2 with the session attribute containing a unique URL for 
the AS#2 to receive media on. 
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Table A.4.3-21 : INVITE request (AS#2 to S-CSCF#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP as2 .home2 . net;branch=z9hG4bK348923 . 1 

Max-Forwards: 70 

Route: <sip: s0 9a233cbsdfglk j4 90303a0@scscf 2 .home2 . net; lr> 

P -As sorted- Identity: 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423551024 " 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=7871654 

To : <sip:user2_publicl@home2 . net> 

Call- ID: 0s0 9glkj4 903a2sdf33cb03a 

Cseq: 210 INVITE 

Contact: <sip: [9999: : ccc : aaa:bbb: ddd] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933630 2987933630 IN IP6 9999 :: ccc : aaa : bbb : ddd 

s=- 

c=IN IP6 as2.home2.net .URL 

t = 

m=message 9999 msrp * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp:// [9999: : ccc : aaa: bbb: ddd] :3333/s317121 



22. 100 (Trying) response (S-CSCF#2 to AS#2) - see example in table A.4.3-22 

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request. 

Table A.4.3-22: 100 (Trying) response (S-CSCF#2 to AS#2) 



SIP/2 


.0 


100 


Trying 














Via: 


SIP/2. 


0/UDP as2 


home2 


net 


bran 


ch= 


=z9hG4bK348923 


1 


From: 




















To: 




















Call- 


ID 


















CSeq: 




















Conte 


nt- 


-Len 


gth: 















23. INVITE request (S-CSCF#2 to P-CSCF#2) - see example in table A.4.3-23 

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. S-CSCF#2 remembers 
(from the registration procedure) the UE Contact address and the next hop CSCF for this UE. 
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Table A.4.3-23: INVITE request (S-CSCF#2 to P-CSCF#2) 



INVITE sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
Max-Forwards: 69 

Route : <sip:pcscf2.visitecl2.net;lr> 
Record-Route : <sip:scscf2. home 2 .net; lr> 
P -Asserted- Identity: 
P-Charging-Vector : 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

P-Called-Party-ID: <sip: user2_publicl@home2 . net> 
Content-Type : 
Content-Length: (...) 



24. 100 (Trying) response (P-CSCF#2 to S-CSCF#2) - see example in table A.4.3-24 

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request. 

Table A.4.3-24: 100 (Trying) response (P-CSCF#2 to S-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



25. INVITE request (P-CSCF#2 to UE#2) - see example in table A.4.3-25 

P-CSCF#2 forwards the INVITE request to the terminating UE. 
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Table A.4.3-25: INVITE request (P-CSCF#2 to UE#2) 



INVITE sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .visited2 . net : 5088; comp=sigcomp;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
Max-Forwards: 68 

Record-Route : <sip:pcscf2 .visited2 . net : 5088; Ir; comp=sigcomp>, <sip: scscf2 . home 2 .net; lr> 
P-Asserted- Identity: 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

P-Called-Party-ID : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



26. 100 (Trying) response (UE#2 to P-CSCF#2) - see example in table A.4.3-26 

UE#2 sends a 100 (Trying) response provisional response to P-CSCF#2. 

Table A.4.3-26: 100 (Trying) response (UE#2 to P-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



27. Reserve IP-CAN bearer for media 

The terminating UE#2 accepts the message session and. UE#2 reserves an IP-CAN bearer for the message 
session media component. 

28. TCP setup 

UE#2 establishes a TCP connection using the IP-CAN bearers established in step 27 to the host address and 
port as specified in the MSRP URL received in the SDP Offer from AS#2. 

29. MSRP VISIT request (UE#2 to AS#2) - see example in table A.4.3-29 

UE#2 sends a MSRP VISIT request to AS#2 using the established TCP connection. 

Table A.4.3-29: MSRP VISIT request (UE#2 to AS#2) 



MSRP VISIT 














Boundary: 194sy2s 














To-path:msrp:// [9999: :ccc 


aaa 


bbb 


ddd] 


:3333/s317121 


From-path: msrp:// 


[5555: 


eee 


fff 


aaa: 


bbb] 


:3335/s417121 


TR-ID: 2810 














Message-ID: 2810 














194sy2s$ 
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Boundary: Boundary string used to terminate message 

To-path: The sender" s remote path 

From-path: The sender" s local URL 

TR-ID: A unique transaction ID for this MSRP transaction. 

Message-ID: A unique message ID for MSRP message. 

Closing: Same boundary string as well as Continuation-Flag 

30. MSRP VISIT request (AS#2 to AS#1) - see example in table A.4.3-30 

AS#2 sends a MSRP VISIT request to AS#1 using the established TCP connection. 

Table A.4.3-30: MSRP VISIT request (AS#2 to AS#1) 



MSRP VISIT 












Boundary: 948qa2q 
To-path :msrp: //[7777::eee 
From-path: msrp : // [ 9999 : : 


:ddd 

ccc : 


: ccc 
aaa : 


: aaa 
bbb: 


] :3927/s222371 
ddd] :3333/s317122 


TR-ID: 1730 












Message-ID: 1730 
948qa2q$ 













Boundary: Boundary string used to terminate message 

To-path: The sender" s remote path 

From-path: The sender" s local URL 

TR-ID: A unique transaction ID for this MSRP transaction. 

Message-ID: A unique message ID for MSRP message. 

Closing: Same boundary string as well as Continuation-Flag. 

31. MSRP VISIT request (AS#1 to UE#1) - see example in table A.4.3-31 

AS#1 sends a MSRP VISIT request to UE#1 using the established TCP connection. 

Table A.4.3-31 : MSRP VISIT request (AS#1 to UE#1) 



MSRP VISIT 












Boundary: i3hd83h 












To-path: msrp: // [5555 : : 


aaa 


bbb : ccc 


ddd] : 


3402/slll271 


From-path :msrp: // [7777 


: : eee : ddd 


ccc:aaa] :3927/s222372 


TR-ID: 1380 












Message-ID: 1380 












i3hd83h$ 













Boundary: Boundary string used to terminate message 

To-path: The sender" s remote path 

From-path: The sender" s local URL 

TR-ID: A unique transaction ID for this MSRP transaction. 

Message-ID: A unique message ID for MSRP message. 

Closing: Same boundary string as well as Continuation-Flag 
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32. MSRP 200 (OK) response (UE#1 to AS#1) - see example in table A.4.3-32 

UE#1 that acts as a MSRP host returns a MSRP 200 (OK) response to the MSRP VISIT request using the 
established TCP connection. 

Table A.4.3-32: MSRP 200 (OK) response (UE#1 to AS#1) 



MSRP 200 OK 












Boundary: 3hdk39f 












To-path:msrp: // [5555 : : 


aaa 


bbb : ccc 


ddd] : 


3402/slll271 


From-path ;msrp; // [7777 


; ; eee ; ddd 


ccc ; aac 


] :3927/s222372 


TR-ID: 1380 












3hdk39f$ 













TR-ID: The transaction ID for this MSRP transaction, as received in the related MSRP request. 

33. MSRP 200 (OK) response (AS#1 to AS#2) - see example in table A.4.3-33 

AS#1 returns a MSRP 200 (OK) response the MSRP VISIT request to AS#2 using the established TCP 
connection. 

Table A.4.3-33: MSRP 200 (OK) response (AS#1 to AS#2) 



MSRP 2 00 OK 

Boundary; 9sne41k 

To-path:msrp: // [7777: : eee : ddd: ccc : aaa] :3927/s222371 

From-patlrL:msrp:// [9999: : ccc: aaa: bbb: ddd] :3333/s317122 

TR-ID: 1730 

9sne41k$ 



TR-ID: The transaction ID for this MSRP transaction, as received in the related MSRP request. 

34. MSRP 200 (OK) response (AS#2 to UE#2) - see example in table A.4.3-34 

AS#2 returns a MSRP 200 (OK) response to the MSRP VISIT request to UE#2 using the estabUshed TCP 
connection. 

Table A.4.3-34: MSRP 200 (OK) response (AS#2 to UE#2) 



MSRP 


(...) 200 OK 












Boundary: skjf93 


J 










To:msrp:// [9999: 


: ccc 


: aaa: bbb 


ddd] : 


3333/s317121 


From: 


[5555: :eee: 


fff : 


aaa 


bbb] 


3335/ 


S417121 


TR-ID 


: 2810 

— skjf93j$ 













TR-ID: The transaction ID for this MSRP transaction, as received in the related MSRP request. 

35. 200 (OK) response (UE#2 to P-CSCF#2) - see example in table A.4.3-35 

After the receipt of the MSRP 200 (OK) response to the MSRP VISIT request, the terminating UE#2 sends a 
200 (OK) response for the INVITE request containing SDP that indicates that UE#2 has successfully visited 
AS#2. 
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Table A.4.3-35: 200 (OK) response (UE#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf2 .visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
Record-Route : <sip:pcscf2 .visited2 . net : 5088; Ir; comp=sigcomp>, <sip: scscf2 . home 2 .net; lr> 
Privacy; none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: <sip : userl_publicl@homel .net>tag=7871654 
To: <sip:user2_publicl@home2 . net>; tag=99945 6 
Call- ID: 0s0 9glkj4 903a2sdf33cb03a 
Cseq: 210 INVITE 

Contact: <sip: [5555: :eee:fff: aaa:bbb] : 8 805; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 29879336302987933630IN IP6 5555 : : aaa : bbb : ccc : ddd 

s=- 

c = IN IP 6 my. MSRP. dummy. URL 

t = 

m=message 9999 msrp * 

a=accept-types : text/plain text/html message/cpim 

a=path:msrp: // [5555: : eee : f f f : aaa:bbb] :3335/s417121 



36. 200 (OK) response (P-CSCF#2 to S-CSCF#2) - see example in table A.4.3-36 

P-CSCF#2 forwards the 200 (OK) response to S-CSCF#2. 

Table A.4.3-36: 200 (OK) response (P-CSCF#2 to S-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
Record-Route : 

P-Asserted-Identity : "John Smith" <sip : user2_publicl@home2 . net> 
Privacy : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423551024 " 
P-Access-Network-Inf o : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



37. 200 (OK) response (S-CSCF#2 to AS#2) - see example in table A.4.3-37 

S-CSCF#2 forwards the 200 (OK) response to AS#2. 
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Table A.4.3-37: 200 (OK) response (S-CSCF#2 to AS#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP as2 .home2 . net; branch=z9hG4bK348923 . 1 

Record-Route ; 

P-Asserted-Identity : "John Smith" <sip : user2_publicl@home2 . net>, <tel ; +l-212-555-2222> 

Privacy ; 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423551024 " ; orig-ioi=homel .net; 

term-ioi=home2 . net 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



38. ACK request (AS#2 to S-CSCF#2) - see example in table A.4.3-38 

AS#2 generates a new ACK request and sends it to S-CSCF#2. 

Table A.4.3-38: ACK request (AS#2 to S-CSCF#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP as2 .home2 . net;branch=z9hG4bK348923 . 1 

Max-Forwards: 70 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 

From: <sip : userl_publicl@homel .net>;tag=7871654 

To : <sip : user2_publicl@home2 .net>;tag=22 17770 

Call- ID: 0s0 9glkj4 903a2sdf33cb03a 

Cseq: 210 ACK 

Content-Length: 



39. ACK request (S-CSCF#2 to P-CSCF#2) - see example in table A.4.3-39 

S-CSCF#1 forwards the ACK request to P-CSCF#2. 

Table A.4.3-39: ACK request (S-CSCF#2 to P-CSCF#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1, 


SIP/2. 0/UDP 


as 2 .home2 . net; branch=z9hG4bK34 8 923 . 1 




Max-Forwards: 69 




Route : <sip:pcscf2.visited2.net;lr> 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length : 





40. ACK request (P-CSCF#2 to UE#2) - see example in table A.4.3.40 

P-CSCF#2 forwards the ACK request to UE#2. 



£75/ 



3GPP TS 24.247 version 6.0.1 Release 6 49 ETSI TS 1 24 247 V6.0.1 (2005-01 ) 

Table A.4.3-40: ACK request (P-CSCF#2 to UE#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 






Via: SIP/2. 0/UDP pcscf2 .visited2 . net : 5088; comp=sigcomp; branch= 


=z9hG4bK361k21.1, 


SIP/2. 0/UDP 


scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 






as 2 .home2 . net ; branch=z9hG4bK34 8 923 . 1 






Max-Forwards: 68 






From: 






To: 






Call-ID: 






Cseq: 






Content-Length : 







41. 200 (OK) response (AS#2 to S-CSCF#2) - see example in table A.4.3-41 

AS#2 generates a 200 (OK) response to S-CSCF#2. 

Table A.4.3-41 : 200 (OK) response (AS#2 to S-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

asl.homel.net;branch=z9hG4bK240f34. 1 
Record-Route : <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel .net; lr> 

P-Asserted-Identity : "John Smith" <sip:user2_publicl@home2 . net>, <tel : +l-212-555-2222> 
Privacy : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323551024 " 
From: <sip : userl_publicl@homel . net>tag=234567 
To: <sip:user2_publicl@home2.net>;tag=98 98 9823 
Call- ID: s0 9a233cbsdfglkj4 90303a0 
CSeq: 278 INVITE 

Contact: <sip: [9999: : ccc : aaa:bbb: ddd] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933640 2987933640 IN IP6 9999 :: ccc : aaa : bbb : ddd 

s=- 

c=IN IP6 as2.home2.net .URL 

t = 

m=message 9999 msrp * 

a=accept-types :message/cpim text/plain text/html 

a= path: msrp: // [9999: : ccc : aaa : bbb : ddd] :3333/s317122 



42. 200 (OK) response (S-CSCF#2 to I-CSCF#2) - see example in table A.4.3-42 

S-CSCF#2 forwards the 200 (OK) response to I-CSCF#2. 
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Table A.4.3-42: 200 (OK) response (S-CSCF#2 to l-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

asl.homel.net;branch=z9hG4bK240f34. 1 
Record-Route : 

P-Asserted-Identity : "John Smith" <sip;user2_publicl@home2 . net>, <tel : +l-212-555-2222> 
Privacy : 
P-Charging-Vector : icid-value"AyretyU0dm+6O2IrT5tAFrbHLso=323551024 " ; orig-ioi=homel .net; 

term-ioi=home2 . net 
P-Charging-Funct ion-Addresses: ccf=[6666: :b99:c88:d7 7:e66]; ccf=[6666: :a55:b44:c33:d22]; 

ecf=[6666: :lff:2ee:3dd:4ee] ; ecf=[6666: : 6aa:7bb: 8cc: 9dd] 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



43. 200 (OK) response (I-CSCF#2 to S-CSCF#1) - see example in table A.4.3-43 

I-CSCF#2 forwards the 200 (OK) response to S-CSCF#1. 

Table A.4.3-43: 200 (OK) response (l-CSCF#2 to S-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

asl.homel.net;branch=z9hG4bK24 0f34. 1 
Record-Route : 
P -Asserted- Identity: 
Privacy: none 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



44. 200 (OK) response (S-CSCF#1 to AS#1) - see example in table A.4.3-44 

S-CSCF#1 forwards the 200 (OK) response to AS#1. 
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Table A.4.3-44: 200 (OK) response (S-CSCF#1 to AS#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP asl .homel . net; branch=z9hG4bK240f 34 . 1 

Record-Route ; 

P -Asserted- Identity: 

Privacy : 

P-Charging-Vector : 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22] 

ecf=[5555::lff:2ee:3dd:4ee]; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



45. ACK request (AS#1 to S-CSCF#1) - see example in table A.4.3-45 

AS#1 generates an ACK request and sends it to S-CSCF#1. 

Table A.4.3-45: ACK request (AS#1 to S-CSCF#1) 



ACK sip: [9999: :ccc:aaa:bbb:ddd] SIP/2.0 

Via: SIP/2. 0/UDP asl .homel . net;branch=z9hG4bK240f 34 . 1 

Max-Forwards: 70 

Route: <sip: scscfl .homel . net; lr>, <sip: scscf2 .home2 . net; lr> 

From: <sip : userl_publicl@homel . net>; tag=234567 

To: <sip:user2_publicl@home2.net>;tag=98 98 9823 

Call- ID: s0 9a233cbsdfglkj4 90303a0 

Cseq: 278 ACK 

Content-Length: 



46. ACK request (S-CSCF#1 to S-CSCF#2) - see example in table A.4.3-46 

The S-CSCF#1 forwards the ACK request to S-CSCF#2. 

Table A.4.3-46: ACK request (S-CSCF#1 to S-CSCF#2) 



ACK sip: [9999: :ccc:aaa:bbb:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel . net; branch=z9hG4bK344a65 . 1, SIP/2. 0/UDP asl . homel . net ; branch= 

z9hG4bK240f34.1 
Max-Forwards: 69 

Route: <sip: scscf2 .home2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



47. ACK request (S-CSCF#2 to AS#2) - see example in table A.4.3-47 

The S-CSCF#2 forwards the ACK request to the AS#2. 
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Table A.4.3-47: ACK request (S-CSCF#2 to AS#2) 



ACK sip: [9999: :ccc:aaa:bbb:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK344a65 . 1, SIP/2. 0/UDP 

asl.homel.net;branch=z9hG4bK24 0f34. 1 
Max-Forwards: 68 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



48. 200 (OK) response (AS#1 to S-CSCF#1) - see example in table A.4.3-48 

AS#1 generates a 200 (OK) response and sends it to S-CSCF#1. 

Table A.4.3-48: 200 (OK) response (AS#1 to S-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK344a65 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel . net; lr>, <sip:pcscfl .visitedl .net; lr> 

P-Asserted- Identity: 

Privacy : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <sip:user2_publicl@home2 . net>; tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq: 127 INVITE 

Contact: <sip: [7777: : eee : ddd: ccc: aaa] > 

Allow: 

Content-Type : 

Content-Length : 

v=0 

o=- 2987933642 2987933642 IN IP6 7777 :: eee : ddd: ccc : aaa 

s=- 

c=IN IP6 asl .homel .net .URL 

t = 

m=message 9999 msrp * 

a=accept-types :message/cpim text/plain text/html 

a=path :msrp://[7777: :eee: ddd: ccc: aaa] :3 927/s222372 



49. 200 (OK) response (S-CSCF#1 to P-CSCF#1) - see example in table A,4,3-49 

S-CSCF#1 forwards the 200 (OK) response to P-CSCF#1. 
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Table A.4.3-49: 200 (OK) response (S-CSCF#1 to P-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route : 
P -Asserted- Identity: 
Privacy : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



50. 200 (OK) response (P-CSCF#1 to UE#1) - see example in table A.4.3-50 

P-CSCF#1 forwards the 200 (OK) response to UE#1 

Table A.4.3-50: 200 (OK) response (P-CSCF#1 to UE#1) 



SIP/2.0 200 OK 

Via: SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel .net; lr>, <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp> 

P -Asserted- Identity : 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

Allow: 

Content-Type : 

Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



51. ACK request (UE#1 to P-CSCF#1) - see example in table A.4.3-51 

The UE responds to the 200 (OK) response with an ACK request sent to the P-CSCF#1. 
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Table A.4.3-51 : ACK request (UE#1 to P-CSCF#1) 



ACK sip: [7777: :eee:ddd:ccc:aaa] SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa:bbb: ccc: ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip: scscfl . homel .net; lr> 

From: <sip : userl_publicl@homel .net>;tag=171828 

To: <sip:user2_publicl@home2 . net>; tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 ACK 

Content-Length: 



52. ACK request (P-CSCF#1 to S-CSCF#1) - see example in table A.4.3-52 

The P-CSCF#1 forwards the ACK request to the S-CSCF#1. 

Table A.4.3-52: ACK request (P-CSCF#1 to S-CSCF#1) 



ACK sip: [7777: :eee:ddd:ccc:aaa] SIP/2.0 


Via: SIP/2. 0/UDP pcscfl .visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 


[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 


Max-Forwards: 69 


P-Access-Network-Inf o : 


Route : <sip:scscfl. homel . net ; lr> 


From: 


To: 


Call-ID: 


Cseq: 


Content-Length : 



53. ACK request (S-CSCF#1 to AS#1) - see example in table A.4.3-53 

The S-CSCF#1 forwards the ACK request to AS#1. 

Table A.4.3-53: ACK request (S-CSCF#1 to AS#1) 



ACK sip: [7777: : eee 


:ddd 


ccc 


aaa] 


SIP/2.0 










Via: SIP/2. 0/UDP scscfl . homel . n 


et;branch= 


=z9hG4bK344a 


65.1, SIP/2. 


0/UDP 


pcscfl. visitedl 


. net. 


branch=z 


9hG4bK240f34. 


1, SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc : ddd] 


1357 


; comp=sigcomp 


;branch= 


z9hG4bKnashc 


s7 


Max-Forwards : 68 


















From: 


















To: 


















Call-ID: 


















Cseq: 


















Content-Length : 



















54. MSRP SEND (UE#1 to AS#1) - see example in table A.4.3-54 

The originating UE sends the first message over the MSRP session with a MSRP SEND request using the 
established TCP connection. 

Table A.4.3-54: MSRP SEND (UE#1 to AS#1) 



MSRP SEND 

Boundary: 34kjf94 

To-path:msrp: // [7777: : eee : ddd: ccc : aaa] :3927/s222372 

From-path:msrp:// [5555: : aaa: bbb: ccc: ddd] :3402/slll271 

TR-ID: 8 822 

Message-ID: 8822 

Content-Type: "text/plain" 

I will never be a member of a club that accepts people like me as members - Groucho Marx. 
34kjf94$ 



Boundary: Boundary string used to terminate message. 
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To-path: The sender" s remote path. 

From-path: The sender" s local URL. 

TR-ID: A unique transaction ID for this MSRP transaction. 

Message-ID: A unique message ID for MSRP message. 

Content-Type: The format of the body of the request. 

Closing: Same boundary string as well as Continuation-Flag. 

55. MSRP SEND (AS#1 to AS#2) - see example in table A.4.3-55 

AS#1 forwards the first MSRP SEND request to AS#2 over the MSRP session using the established TCP 
connection. 

Table A.4.3-55: MSRP SEND (AS#1 to AS#2) 



MSRP SEND 




Boundary: shfsoi3 




To-path :msrp:// [9999: : ccc : aaa:bbb:ddd] :3333/s317122 




From-path :msrp:// [7777: : eee :ddd:ccc:aaa] :3927/s222371 




TR-ID: 2832 




Message-ID: 2832 




Content-Type: "text/plain" 




I will never be a member of a club that accepts people like me as members - 


- Groucho Marx. 


shfsoi3$ 





Boundary: Boundary string used to terminate message. 

To-path: The sender" s remote path. 

From-path: The sender" s local URL. 

TR-ID: A unique transaction ID for this MSRP transaction. 

Message-ID: A unique message ID for MSRP message. 

Content-Type: The format of the body of the request. 

Closing: Same boundary string as well as Continuation-Flag. 

56. MSRP SEND (AS#2 to UE#2) - see example in table A.4.3-56 

AS#2 forwards the first MSRP SEND request to UE#2 over the MSRP session using the established TCP 
connection. 

Table A.4.3-56: MSRP SEND (AS#2 to UE#2) 



MSRP SEND 




Boundary: 2oid4sf 




To-path :msrp:// [5555: : eee : f f f : aaa : bbb] :3335/s417121 




From-path :msrp:// [9999: : ccc : aaa : bbb : ddd] :3333/s317121 




TR-ID: 3311 




Message-ID: 3311 




Content-Type: "text/plain" 




I will never be a member of a club that accepts people like me as members - 


- Groucho Marx. 


2oid4sf$ 





Boundary: 

To-path: 

From-path: 



Boundary string used to terminate message. 
The sender" s remote path. 
The sender" s local URL. 
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TR-ID: A unique transaction ID for this MSRP transaction. 

Message-ID: A unique message ID for MSRP message. 

Content-Type: The format of the body of the request. 

Closing: Same boundary string as well as Continuation-Flag. 

57. MSRP 200 (OK) response (UE#2 to AS#2) - see example in table A.4.3-57 

The receiving UE#2 acknowledges the reception of the MSRP SEND request with a MSRP 200 (OK) 
response sent using the established TCP connection. 

Table A.4.3-57: MSRP 200 (OK) response (UE#2 to AS#2) 



MSRP 200 OK 

Boundary: 2j32ri3 

To-path:msrp:// [5555: : eee : f f f : aaa :bbb] :3335/s417121 

From-path:msrp: // [9999: : ccc : aaa:bbb: ddd] :3333/s317121 

TR-ID: 3311 

2j32ri3$ 



TR-ID: The transaction ID for this MSRP transaction, as received in the related MSRP request. 

58. MSRP 200 (OK) response (AS#2 to AS#1) - see example in table A.4.3-58 

AS#2 acknowledges the reception of the MSRP SEND request with a MSRP 200 (OK) response to AS#1 
using the established TCP connection. 

Table A.4.3-58: MSRP 200 (OK) response (AS#2 to AS#1) 



MSRP 200 OK 












Boundary: wnhus9o 












To-path:msrp: // [9999: : 


ccc 


aaa : bbb 


ddd] : 


3333/s317122 


From-path :msrp: // [7777 


: : eee 


ddd:ccc:aaa] :3927/s222371 


TR-ID: 2832 












wnhus9o$ 













TR-ID: The transaction ID for this MSRP transaction, as received in the related MSRP request. 

59. MSRP 200 (OK) response (AS#1 to UE#1) - see example in table A.4.3-59 

AS#1 acknowledges the reception of the MSRP SEND request with a MSRP 200 (OK) response to UE#1 
sent using the established TCP connection. 

Table A.4.3-59: MSRP 200 (OK) response (AS#1 to UE#1) 



MSRP 200 OK 

Boundary: 3is09wh 

To-pat h:msrp://[7777: :eee: ddd: ccc: aaa] :3 927/s222372 

To-patli :msrp ://[7777::eee: ddd: ccc: aaa] :3927/s222372 

TR-ID: 8822 

3is09wli$ 



TR-ID: The transaction ID for this MSRP transaction, as received in the related MSRP request. 

A.4.4 Establishing a session for session-based messaging with 
preconditions 

This signalling flow is not provided as it is the same as the session establishment flows with preconditions in 3GPP TS 
24.228 [4] except that the SDP contents are for setting up MSRP sessions over TCP rather than RTP sessions over 
UDP. 
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A. 5 Flows demonstrating session-based messaging 
conferences 
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